      *      *                   *     *                          *
      **     *                   **   **                          *
      * *    *             *     * * * *          *          *    *
      *  *   *   *****  *******  *  *  *   *****  ******  ******* ******
      *   *  *  *     *    *     *     *  *     * *     *    *    *     *
      *    * *  *******    *     *     *  *     * *     *    *    *     *
      *     **  *          *     *     *  *     * *     *    *    *     *
      *      *   ******    *     *     *   *****  *     *    *    *     *
      *                                                                 *
      *             The guide to BITNET servers and services            *
      *                                                                 *
      *  Volume 1  Number 10                                April 1987  *
      *                                                                 *
       *****************************************************************
      *                                                                 *
      *  Editor:                          Chris Condon  CONDON@YALEVMX  *
      *  Assistant Editor:                Steve Sutter  SUTTER@YALEVMX  *
      *  NetMonth Staff Supervisor:       Gary Moss       MOSS@YALEVMX  *
      *                                                                 *
       *****************************************************************
      *                                                                 *
      *                                                                 *
      *                                                                 *
      *           Leaders are people who do the right things.           *
      *           Managers are people who do things right.              *
      *           There has been too much attention to doing            *
      *           things right, and not enough emphasis on              *
      *           doing the right thing.                                *
      *                                                                 *
      *                                   -- Warren Bennis              *
      *                                                                 *
      *                                                                 *
      *                                                                 *
      *                                                                 *
      *                                                                 *
      *                                                                 *
      *                                                                 *
      *              elephant is like a wall     ke a                   *
      *           An                           i       p                *
      *                                       l        i    l           *
      *        a                                 o     e    i           *
      *       r                                   f    c     k    ake   *
      *       o                                   c    e     e   n      *
      *       p                                    loth       a s       *
      *       e                                                         *
      *                                                                 *
      *                                                                 *
      *            An ele               phant                           *
      *    is      is lik               e a t                           *
      *   mushy     ree t                runk                           *
       *****************************************************************

1


   *************************************************************************
  * Contents                                                                *
  ***************************************************************************

  Bitnotes ................................................................ 1

  TAKE NOTE__________________________________________________________________

  Scuttlebut .............................................................. 2
  The PSUVM/OHSTVMA Link .................................................. 4
  Global Students Network ................................................. 5

  FEATURES___________________________________________________________________

  Mail Manners ............................................................ 7
  The BITNET Domains Task Force Report .................................... 8

  SERVERS AND SERVICES_______________________________________________________

  Spotlight Server:  DATABASE@BITNIC ..................................... 13
  New Mailing Lists ...................................................... 15

  DEPARTMENTS________________________________________________________________

  Feedback ............................................................... 16
  Policies ............................................................... 17

  NetMonth is a  network service  publication  distributed free  of charge to
  students and professionals in BITNET and other networks.  This magazine and
  it's  companion  file, BITNET SERVERS, are  the work  of the  Yale Computer
  Center  BITNET  Services  Library  (BITLIB) staff.  The  BITLIB  is a local
  online help  facility designed to  inform  Yale network  users  about  what
  services are available  to them  through BITNET, and  provide  instructions
  and  utilities  for their  proper use.  In publishing  NetMonth  the BITLIB
  staff  members hope  to share the  fruits of their  labor with institutions
  outside of Yale in  order to promote a productive  and enjoyable networking
  environment for everyone.

  BITNET SERVERS is BITNET's most  complete  and  up-to-date  list of servers
  and services.  It is sent to  NetMonth  subscribers at the same time as the
  magazine.  BITNET SERVERS is dependent  on your support to remain accurate.
  If you know of servers and  services  not  listed  in BITNET SERVERS, or of
  those listed in the file that  are no longer available, please  contact the
  NetMonth staff at BITLIB@YALEVMX.

  For information  on  subscribing  to NetMonth  and  BITNET SERVERS, see the
  "Policies" section on the last pages of this issue. Within "Policies" there
  are also instructions for  submitting  articles,  sending  Letters  to  the
  Editor, and printing this file.

  ------------------------------------------------------

  A publication of the Bitnet Services Library          "Because We're Here."
1

                                                                       Page 1


   *************************************************************************
  * Bitnotes                                                        Issue 9 *
  ***************************************************************************

             *                                *       *
             *                                *       *
             *                                *       *
             *                                *       *
             *              *                 *   *   *
             *                       *        *       *
             *   *  *       *   * * * * * *   *   *   *   *  *
             *         *    *        *        *   *   *         *
             *          *   *        *        *   *   *          *
             *          *   *        *        *   *   *          *
              *        *    *        *        *   *    *        *
                 *  *       *        *        *   *       *  *


  The Bitnet Services Library (BITLIB)  is  an online help facility providing
  Yale VM users with information on  file servers,  name servers,  electronic
  magazines,  and other  services.   It includes specific   usage information
  for each server,  explanations  of basic concepts (such as "What  is a file
  server?")  and a  set of useful EXECs  to  make life  with  BITNET  easier.
  All documentation  has been tailored to the VM environment.

  BITLIB is  currently   undergoing  conversion from  YHELP to   the  new SP4
  HELP facility.    After the  changes  have  been  made,  we would   like to
  make BITLIB available for installation   at other nodes.   Distribution and
  monthly updates would be handled in the same way as Listserv and Relay.

  BITLIB has been  serving users  at Yale  since  May of 1985.   At this time
  the we  would  like  to  monitor  interest  in  the service.    If you  are
  interested  in  installing  BITLIB  at your  node,   or  would   like  more
  information, please  send mail to BITLIB@YALEVMX.

  ---------------------------------------------------------------------------

  This announcement was  posted on the LIAISON list  in mid-April.   Response
  has been  much greater  than expected.    Conversion to  SP4 HELP  has been
  completed, and a beta-test site will be implemented soon.

  ---------------------------------------------------------------------------

  There are new instructions for subscribing  to NetMonth!    We have finally
  given  in to  technology  and will  now  let  LISTSERV handle  subscription
  requests.   If  you are  already on  the mailing  list you  do NOT  need to
  request a subscription from LISTSERV.  Many thanks to A. Harry Williams for
  setting up the list at MARIST.
1

                                                                       Page 2


  * Subscribing to NetMonth and BITNET SERVERS:

  VM users can be added to the mailing list by issuing the following command:

      TELL LISTSERV AT MARIST SUBSCRIBE NETMONTH Your_full_name

  VAX/VMS users can subscribe in a similar way:

      SEND LISTSERV@MARIST SUBSCRIBE NETMONTH Your_full_name

  If you cannot send messages in this way, you can send the following command
  as the first line of a mail file to LISTSERV@MARIST:

      SUBSCRIBE NETMONTH Your_full_name

  Arpanet users may use this method, but must address the mail to:

      LISTSERV%MARIST.BITNET@WISCVM.WISC.EDU

  ---------------------------------------------------------------------------

  They said it couldn't be done:  Pending  successful  completion  of  all my
  classes, I will graduate on May 16th.  After that I will be going to NetCon
  Spring 1987  (New Orleans)  to speak on the  Past and Future  of BITNET.  I
  will still be working on BITLIB and NetMonth after these  momentous  events
  (just in case  you thought that my graduation meant  that I  wouldn't  keep
  doing this.  I'm having too much fun).


                             Chris Condon@YALEVMX


   *************************************************************************
  * Scuttlebut                                                              *
  ***************************************************************************

  The Lives and Deaths Relays:

  * Thanks to Jeff Kell and Jose Flores for the notice that there is now a
  Relay at UCSVM.

  * This news from Jeff Kell:

  Due to the withdrawal of the Relay server at NCSUVM, coupled with heavy
  network traffic which prohibits reassigning the affected sites to another
  server, the following nodes are being excluded from Relay service pending
  establishment of another server with better placement:

  APLVM    ARSBARC  AUVM     BAGAMCOK BKNLVMS  BRCVAX   BUCKNELL CEBAFVAX
  CUA      DICKINSN DUKE*    ECSVAX   ECUVM1   GALLU*   GMUVAX   GUNBRF
1

                                                                       Page 3


  GUVAX    GUVM     GWUVAX   GWUVM    HUMAIN   IUP      JHU*     JMUVAX1
  JPSPHVAX LOYVAX   MUSCVM   NBS      NCSU*    NIH*     NRAO     NSF
  ODUVM    PSU*     SCF*     SEASVM   TUCC*    UC780    UDCVM    UMAB
  UMBC*    UMCINCOM UMD*     UME*     UMUC     UNC*     UNIVSCVM USGSRESV
  USUHS    VCU*     VIRGINIA VP*      VT*      WMHEG    WMMVS

  I am  providing this  information in advance  in anticipation  of inquiries
  and/or  flames from  users at  these sites.    There  is simply  no way  to
  continue service to these  sites without undue load being placed  on one or
  more critical hub links (CUNY-PSU, PSU-CORNELL, PSU-OHSTVMA).

  The  server at  UWF will  continue to  service  sites south  of TUCC;   the
  affected region is from TUCC to PSUVM,  including the area around PSUVM not
  on the CUNY, Cornell, or OHSTVMA paths.

  To avoid a lengthy discourse that won't change anything, accept it.

  Due to network loading and the sites  served by NCSUVM,  it is necessary to
  exclude (yes;  exclude, omit, delete, no-speakie)  their prior service area
  until some other suitable server can be found or established.   This too is
  a fact which cannot be changed.

  PLEASE don't  post 20-30  entries of  how terrible  this is,   how somebody
  should do something,   how node XYZZY should  get a Relay,  why  can't Y2's
  Relay serve them for now,  etc.,  etc.    There is nothing more to be done.
  Cornell can't pick  them up since it would load  PSU-Cornell,  Bitnic can't
  pick them up since it would load  PSU-CUNY,  and Pittsburgh can't pick them
  up since it would load PSU-OHSTVMA.   And UWF can't serve the universe from
  the  bottom  of the  southeast  branch  of  the network  (nothing  critical
  intended -- wish I was in Florida).

  We have avoided  denial of service for  nearly two years now,   that's good
  enough,  but  it can't last.    Those of us who  actually host a  Relay and
  donate the  time (personal as well  as CPU)  and resources,   usually going
  against all odds to justify in the first place, have done quite well.  NCSU
  did an outstanding job...  they were one of  the first,  Relay has a lot of
  Alan's code in it,   and when Cornell and Bitnic had to  close the doors to
  the PSU area due to CPU and/or link loading, it was NCSU that let them back
  in.  That very well may have contributed to their downfall in the end.  And
  I don't want to  see any other Relays face similar  cases simply because we
  are *still* trying to provide service to *everyone*.   I'm sure some of you
  out  there  know  what  I  mean (UWAVM  serving  half  the  west  coast  by
  themselves, among others).

  Well,  enough of this discourse,  I should  hush.   On with the actual mail
  postings related to the  event...  I have to find my  asbestos underwear as
  I'm sure my personals are going to be flamed in the near future...

  * Thanks  to Tony Dahbura for  the news that SERVER@SUZEUS  (just announced
  last month) will no longer be avaialble due to system performance problems.
1

                                                                       Page 4


   *************************************************************************
  * The PSUVM/OHSTVMA Link                                                  *
  ***************************************************************************

  Summary by Ross Patterson,  Rutgers University
             Bill Rubin, City University of New York

  RSCS Incompatibilities Cause Link Backlog

  We  recently  experienced  a  heavy  backlog  on  the  PSUVM/OHSTVMA  link,
  apparently caused  when OHSTVMA  installed RSCS Version  2 to  replace RSCS
  Version 1.3.   As a result,  PSUVM had to run the DMTNJI line driver on the
  link,  rather than on DMTVMB.   Since the DMTVMB line driver is unavailable
  for RSCS V2, OHSTVMA could no longer use it.  Previously, this driver, used
  for RSCS V1-to-RSCS V1 connections, provided performance benefits when both
  ends of the link ran RSCS V1.   When  IBM built RSCS V2,  they selected the
  DMTNJI line driver as the network  standard since it could communicate with
  any IBM networking system as well as a number of non-IBM systems.

  RSCS V1's DMTNJI line driver has weak points.   For example,  messages from
  one user to  another and commands from a  user to a remote  system were not
  blocked.   RSCS V1 sends each message or command (over a DMTNJI link)  in a
  separate buffer,  regardless of length.   Since the usual buffer size for a
  DMTNJI link is 400 bytes and the maximum message/command size is 256 bytes,
  resources were being wasted.  Consequently, RSCS V2 programmers implemented
  message blocking procedures, so that several messages could share a buffer.
  Since all systems, including RSCS V1,  can receive such buffers,  it seemed
  pointless to retro-fit this feature into RSCS V1.

  A second weakness involved RSCS's preference  to send messages and commands
  before  it sends  data blocks  or  files.   Because  BITNET uses  messaging
  extensively,  a  problem began to develop  when the PSUVM/OHSTVMA  link was
  apparently sending messages almost to the exclusion of files.


  Fixes

  OHSTVMA ran another RSCS V1 (called OHSTMPA) to communicate with PSUVM,  so
  they could both use the DMTVMB  line driver.   The OHSTMPA/OHSTVMA link,  a
  DMTNJI  line,  runs  over  a virtual  Channel-To-Channel  adapter,  a  fast
  networking connection.   Consequently,  the problem  is avoided on the slow
  (PSUVM/OHSTMPA)  connection,  and the with the speed of the fast connection
  (OHSTMPA/OHSTVMA) the problem never existed.

  IBM has accepted an APAR (Authorized Problem Analysis Report)  against RSCS
  V1,  and  will modify  the Version 1  DMTNJI line  driver to  send multiple
  messages in a  single buffer.   When this  fix is installed at  PSUVM,  the
  PSUVM/OHSTVMA  connection  will  be  operational,    and  OHSTMPA  will  be
  eliminated.
1

                                                                       Page 5


  Who might have this problem?

  Most VM-to-VM sites, currently running the DMTVMB line driver between them,
  could have this problem when only one site converts to RSCS V2.  No problem
  exists if both sides convert to RSCS V2.   If one site converts to RSCS V2,
  the RSCS V1 site should apply the APAR fix.


  How can the problem be avoided?

  Once  the APAR  fix VM27826  is tested  and becomes  available through  IBM
  Support Centers, all RSCS V1 sites should install the APAR fix.


   *************************************************************************
  * Global Students Network                                                 *
  ***************************************************************************

  By Toshi Tsubo                                                        Tokyo

  The  Global  Students  Network  is a  student  organization  interested  in
  building a global community of students  using computer networks.   We feel
  that such a network  will help develop necessary human resources  such as a
  global perspective and communication skills for conflict resolution.

  We plan  to organize our group  through a multi-media  communication system
  including:

  o BITNET : e-mail, mailing lists gatewaying with ARPA Internet (USA), CSNET
  (USA), JANET (UK), EANnet (Europe),  CDNnet (Canada),  COSAC (France),  DFN
  (Germany),  ASCNET  (Australia),  UUCP/USENET (USA),  EUnet  (Europe),  SDN
  (Korea), JUNET (Japan).

  o DASNET :   e-mail,  parallel conferences linking  ARPANET,  BITNET,  BIX,
  CompuServe, CSNET, EasyLink, EIES, ENET, GEnie, MCI Mail, NWI,  Santa Clara
  Univ, The Source, Stanford Univ, TWICS, Unison, UUCP.

  o Other media : Telephone, Telex, Fax, Video and Paper.

  Our group will concentrate on several projects.  They will be :

  o General Administration and Finance.

  o  Creating,  maintaining  and distribution  a  network map  and a  members
  directory.

  o Inter-networking and networking technologies.
1

                                                                       Page 6


  o Establishing and organizing a mailing  list or other communication system
  where students can interact in other  language environments.   This will be
  called the "Multi-Language Learning Environment".

  o A service to assist students in their travels and facilitate face to face
  meetings.

  o  An electronic  pen pal  system for  younger children  using the  network
  established  by the  Global Students  Network.    This will  be called  the
  "Global Kids Link".

  If you are anyone you know is  interesting in participating or knowing more
  about this project, please write to one or more of the following addresses:

  Toshi Tsubo
  Central Meguro 102
  2-7-10 Mita, Megruo-ku
  Tokyo  153

  Joichi Ito
  4800 South Lake Shore Drive
  Apartment 1910-S
  Chicago, IL 60615

  Kevin Barron, Vancouver, Canada

  Bitnet:     USERZABL@SFU.BITNET
  PeaceNet:   jito
  Telemail:   Ã•J.ITO/BUSCOMMÃ¥ TELEMAIL/USA
  The Source: BBJ294
  NWI/PARTI:  JOICHI ITO
  Unison:     JOICHI (partiname: JOICHI ITO)
  CompuServe: 70116,502
  TWICS:      TSUBO (partiname: TOSHI TSUBO)
  GreenNet:   TOSHI
  MCI mail:   Toshihiro Tsubo

                     elephant is like a wall     ke a
                  An                           i       p
                                              l        i    l
               a                                 o     e    i
              r                                   f    c     k    ake
              o                                   c    e     e   n
              p                                    loth       a s
              e


                   An ele               phant
           is      is lik               e a t
          mushy     ree t                runk
1

                                                                       Page 7


   *************************************************************************
  * Mail Manners                                                            *
  ***************************************************************************

  From the file MAIL MANNERS, available from NICSERVE@BITNIC.

  The Phenomenon of FLAMING

  The following was from:  Toward an Ethics and Etiquette for Electronic Mail
  written by  Norman Z.   Shapiro and  Robert H.   Anderson prepared  for the
  National Science Foundation and published by The Rand Corporation.

  Perhaps the  attribute of electronic  mail systems that  most distinguishes
  them from other forms of communication is their propensity to evoke emotion
  in the recipient--very likely because  of misinterpretation of some portion
  of  the  form or  content  of  the  message--and  the likelihood  that  the
  recipient will  then fire  off a  response that  aggravates the  situation.
  Possible causes for this phenomenon include:

  - Difficulty in determining the formality of a message from its appearance.

  - Attempts at humor, irony, sarcasm, and wit are often misinterpreted.

  - Cues such as body langauge are lacking in electronic mail.

  - The  ease of an  immediate "reply" encourages "off  the top of  the head"
  responses.

  - Electronic  messages containing  hasty or  ill-chosen words  can stay  in
  electronic inboxes or can be printed in a way (injet, etc.) that gives them
  an importance never intended.

  - Although anonymity is  often mentioned as a factor,  we  have observed no
  significant difference in "flaming" between remote correspondents who don't
  know each other  personally,  compared with communication  among people who
  know each other.

  What  can be  done to  minimize the  problems of  escalating emotions  that
  arise?

  -  Carefully  label messages  that  have  a deliberate  emotional  content.
  Sometimes just  the annotation "Flame!   Flame!"  alerts the reader  to the
  fact that the writer knows he or she is being emotional.

  - Resist the temptation to fire off a response.   Write the response,  file
  it away, and wait 24 hours.  Reconsider the response later, in the light of
  a new  day (and perhaps  a rereading  and reinterpretation of  the original
  message).
1

                                                                       Page 8


  - Use  alternative media  to break the  cycle of  message-and-response.   A
  telephone call  or personal conversation can  do wonders,  when we  can use
  body language, eye contact, and the other cues we've developed.

  Much of  the problem seems  to stem from the  lack of cues  that electronic
  mail affords its readers.   Perhaps  the technology that spawned electronic
  mail can  help reduce the misunderstandings  it creates.   One  can imagine
  message systems  in which  the boldness  of the  characters displayed  is a
  function of the force with which the keys are hit.  More certainly (because
  the systems are in prototype form already)   there will be systems in which
  the  characters will  be accompanied  by  voice annotations,   so that  the
  humanity  and state  of  the sender  will  be retained  and  "read" by  the
  recipient.

  Toward an Ethics and Etiquette for  Electronic Mail,  published by the Rand
  Corporation with support  from the National Science  Foundation,  discusses
  issues  related to  the use  of electronic  mail  and the  effect of  these
  systems  on  the  quality  and  appropriateness  of  communication.    More
  importantly,  it  presents a  set of  guidelines that  should help  lead to
  effective electronic mail use.

  Readers  should be  familiar with  electronic mail  systems or  considering
  adopting them for  individual or institutional use.    Copies are available
  for  $4 from  The Rand  Corporation,  Publications  Department,  1700  Main
  Street, P.O.   Box 2138, Santa Monica, CA 90406-2138.   Ask for publication
  R-3283-NSF/RC.


   *************************************************************************
  * BITNET Domains Task Force Report                                        *
  ***************************************************************************

  This article  was condensed  from the  original report.    You can  get the
  complete report (the file DOMTASK LISTING) from NICSERVE@BITNIC.

                         BITNET DOMAINS TASK FORCE

                        Report and Recommendations
                     to the BITNET Executive Committee

  The  BITNET  executive   committee  directed  Joe Yeaton of  UCB and Leland
  Williams of TUCC to form a Domains Task Force.  The stated mission  of  the
  task  force  is  to  identify  BITNET's requirements for domains and domain
  servers and then to propose technical solutions to those requirements.

  The task force  recently met during the SHARE 66   conference  in  Anaheim,
  discussed  the issues, and developed a set of recommendations which follow.
  The meeting was led by Jim Walker of TUCC and David  Wasley  of  UCB,  each
  appointed to the task by their respective directors.
1

                                                                       Page 9


  The  Domains Task  Force recommends that the following actions  be taken by
  the BITNET Executive Committee, the Domains  Task  Force,  and  the  BITNET
  Network Information Center, respectively:

     1. The  Executive  Committee  should  officially  acknowledge  that
        BITNET will  adopt  the  DARPA  Internet  domain  hierarchy  and
        top-level domain names.

     2. The  Executive  Committee should contact the appropriate Defense
        Communications  Agency  (DCA)  representative  to obtain  formal
        cooperation and coordination of use of top level domain names.

  The   flat  name   space  has  become  difficult  to  manage   and  is  too
  restrictive.  Therefore, a hierarchical name space should be adopted.

  For essentially the  same reasons that the ARPANET   community  decided  to
  move from a flat to a hierarchical name space, we also feel that it is time
  to begin the move in that direction:

     1. Maintaining unique and still meaningful node names within the  8
        character limit is difficult.  This limit has led to the problem
        that the user of BITNET has  trouble  determining  what  site  a
        given node name represents.

     2. Maintaining  and  distributing a database containing the name of
        every machine on the network is awkward  and  will  continue  to
        impose delays in making new nodes accessible.


  Adopting  a  hierarchical   naming strategy built on top  of the underlying
  link-level RSCS  node  names  addresses  both  the  naming  and  management
  problems:

     1. Domain  names  are not artificially limited to some small number
        of characters.  With domain names, the common misconception that
        "CUVMA"  and  "CUNYVM"  are both nodes at Columbia University or
        City University of New  York  (or  Cornell  University)  can  be
        eliminated;   a  domain  name  of  "CUVMA.COLUMBIA.EDU"  clearly
        identifies  the  site  as  an  educational   institution   named
        Columbia.

     2. Hierarchichal naming gives the organization control over its own
        namespace and only requires agreement on a single  name  in  the
        containing  namespace  used  to identify that organization.  Two
        sites can even have a machine with  the  same  name  ("VMA"  for
        example)  and  not have a conflict since their containing domain
        name will be unique  ("VMA.COLUMBIA.EDU"  and  "VMA.CORNELL.EDU"
        for example).
1

                                                                      Page 10


  Within  the  constraints of the RSCS  network,  unique node names are still
  required to maintain full connectivity.    However,  node  names,  although
  unique,  need not be meaningful to the user since he or she will be dealing
  with a higher-level domain name.

  The fundamental concept here  is to consider  the  RSCS  node   name  as  a
  low-level   "network   address."    The  user  sees  a  domain  name  which
  higher-level software will map to the network address "under  the  covers."
  This  is  analagous to the mapping done on the ARPANET between domain names
  and IP host numbers (which are 32-bit integers).  These  network  addresses
  (RSCS  nodes,  IP host numbers) still need to be unique, but the problem of
  making them meaningful to the user goes away; the  user  gets  the  meaning
  from the domain name.

  The  use  of domain  naming may eventually allow a reduction  in the number
  of BITNET nodes that require full RSCS-level connectivity.  Only  the  node
  at  a  site  physically connecting that site to the RSCS network need be in
  all other sites' RSCS route tables.  That  connected  node  serves  as  the
  routing  gateway  between  the  long-haul  RSCS network and the rest of the
  site's nodes.   A  complete  domain-level  software  layer  that  minimally
  provides  the  same functionality currently provided at the RSCS level must
  exist in order for this to work.

  An example where  this domain-level software capability   currently  exists
  is  with  mail:   If all other BITNET sites that wanted to communicate with
  Columbia users also ran a mail transport agent like UCLA/Mail (MVS) or  the
  Columbia  Mailer  (VM), then only RSCS node CUVMA would need to be in other

  site's route tables; their  mailers  would  know  that  all  mail  for  the
  COLUMBIA.EDU  domain  should  be  routed to the mailer on CUVMA which would
  take care of  local  redistribution  within  the  university's  local  area
  network.   Of course, other network functions such as interactive messaging
  (TELL) or file transfer (SENDFILE) would need to be modified to incorporate
  similar routing algorithms.

  Assuming  that   a hierarchical name space  is adopted,  it  is recommended
  that this  name space be  based upon the DARPA  Internet model and  use the
  same top-level domain names.

  The  DARPA domain model is geography  and network independent;  it reflects
  the  natural  admininistrative  hierarchy  of   organizations   and   their
  peer-to-peer  relationship  --  not  location  or  how  they are connected.
  Domain names that reflect the method  of interconnection such  as  .ARPA or
  .BITNET  are to be avoided.  The .ARPA domain was used in the transitionary
  period between the flat and hierarchical name spaces in the ARPANET.    The
  implementors  have  since  stated  that it was a mistake to ever get people
  accustomed to this naming hierarchy.  The task force feels that there is no
  point  in reinventing the wheel.  We would rather adopt the DARPA model (as
  has been done before for mail) than come up with our own model.   This  has
1

                                                                      Page 11


  special importance to the large number of BITNET sites that are also on the
  other DARPA Internet-compatible networks (ARPANET, MILNET, CSNET).

  Use  of  the  same  top-level Defense  Data  Network  (DDN)   domain  names
  (.EDU,.COM,  etc.)   will  require  the  cooperation  of  the  DDN  Program
  Management Office (PMO) of the U.S. Defense Communications Agency (DCA) and
  coordination  with the DDN Network Information Center  and with the DDN PMO
  contracting department(s) on those campuses that are on both networks.   At
  a  meeting at SRI attended by Candy Willut of EDUCOM and representatives of
  ARPANET, CSNET, and UUCP it was agreed  that  these  networks  joining  the
  Internet  would  be  beneficial  to all concerned.  However, SRI is not the
  official policy-setting representative of the DCA.

  We recommend that  formal cooperation be  agreed  upon   by  the  executive
  committee  and  the appropriate DCA representative.  Furthermore, for sites
  on both networks,  administrative  cooperation  is  necessary  between  the
  BITNET site administration (typically the computer center) and the DDN site
  administration (typically the computer science department).

  The current unoffical (from the standpoint  of DARPA)  use of DARPA  domain
  naming  within  BITNET  has  led to problems when mail crosses the boundary
  from BITNET to ARPANET; when the user on the ARPANET tries to reply to  the
  mail,  it  is  found  that  the  BITNET  site's  top-level  domain  or some
  sub-domain is not registered in the appropriate domain names database.

  For example,  mail  sent  from   CUVMA.COLUMBIA.EDU  (RSCS  node  CUVMA  on
  BITNET) to someone on ARPANET results in something similar to the following

  scenario: The replying mail server  will  query  the  SRC-NIC  name  server
  (since  it is the authorized server for the EDU domain) for the name server
  for the COLUMBIA.EDU domain.  SRI-NIC will  respond  with  the  address  of
  COLUMBIA.EDU,  a  VAX  11/750 administered by the Columbia Computer Science
  department.    Upon  asking  this  name   server   for   the   address   of
  CUVMA.COLUMBIA.EDU,    the    mail    server    will   be   informed   that
  CUVMA.COLUMBIA.EDU does not exist since it is not registered.

  Although the CS  department could register the BITNET hosts  at Columbia in
  their  name  server, they might be reluctant to carry mail traffic from DDN
  to BITNET and especially vice-versa unless the DDN  PMO  acknowledges  that
  this  is  a  valid  use of DDN resources.  This is why explicit cooperation
  between the BITNET Executive and DDN is a requirement.

  Some organization is  required to administer the name space  for sites that
  have only a BITNET connection, from the DDN point of view.  BITNIC,  as  an
  agent  of  the executive committee, is the place for such an administrative
  function.  Since SRI-NIC is the official registrar  for  subdomains  within
  the  top-level  EDU  domain,  a  means of registering these BITNET-only EDU
1

                                                                      Page 12


  BITNET  can  not  count   on IBM to provide software to  support the above.
  Therefore, we are explicitly acknowledging that non-IBM  software  will  be
  required.

  Unmodified,   vendor-supported  network  transport  mechanisms (e.g.  RSCS,
  JES, jnet, etc.) should be used; hierarchical name support will be  layered
  on  top  with additional software developed by BITNET members.  This is not
  an endorsement of the vendor software as being the best way to interconnect
  BITNET.   It is recognition of the fact that this is the way the network is
  currently connected.  We do not wish to recommend that  sites  must  modify
  their  vendor-supplied  software  to  participate  in  the  network (at the
  transport layer).

  We do wish to  drive home the point that although  vendor software for  the
  network  transport  functions  can  be  vanilla,  sites  will  have  to run
  modified, complete replacement, and/or additional applications software  in
  order  to participate effectively in the Internet.  It should be made clear
  to existing and potential BITNET members that they can not expect  to  have
  the  same functionality as other members unless they use this additional or
  changed software.

  The use of   hierarchical  names  rather  than  RSCS  node   names  as  the
  fundamental  user-visible  method  of  addressing another user implies that
  this hierarchical support should encompass all or  many  of  the  functions
  currently provided by the base RSCS network:

     - mail
     - file transfer
     - interactive messaging
     - RJE/RJO
     - remote commands
     - remote login (not really feasible using current low-speed links)
     - etc.

  We recognize that some  or all of these recommendations may  not  apply  to
  the  environments of our peer RSCS networks, EARN and NETNORTH.  The use of
  DARPA domain names is not meant to address their environment  but  that  of
  United States BITNET sites and should not be construed as the only solution
  or one that we expect non-US sites to adopt.

  Specifically,  EARN/NETNORTH sites may  prefer   to  implement  some  other
  naming scheme more compatible to their environments (e.g. CCITT X.400).

  We  of course  intend to maintain and enhance the  interconnectivity of our
  networks.   Nothing  recommended  here  should  be  construed  as  impeding
  cooperation with EARN/NETNORTH.

  We believe these  recommendations to be  the  current   best  solution  and
  realize  that  there  will  be  and  fully  expect future changes that will
  augment or supersede the recommended solutions presented here.
1

                                                                      Page 13


   *************************************************************************
  * Spotlight Server: DATABASE@BITNIC                                       *
  ***************************************************************************

  DATABASE is a  sophisticated database server developed for  BITDOC by Henry
  Nussbacher,  consultant,  City University of  New York.   DATABASE provides
  user specified keyword  access to subsets of  larger databases.   Retrieval
  capabilities are based on SPIRES, the Stanford Public Information Retrieval
  System.

  A Subfile  is the largest structure  in which information is  stored within
  SPIRES on DATABASE.    Three types of subfiles  include Demonstration Files
  such as MOVIES  or RECIPES used to gain experiance  with DATABASE,  Network
  Digests such as AI-LISTS an archive of a discussion forum maintained within
  ARPANET,   and  General Information  Files  such  BITINFO the  BITNET  node
  identification subfile.

  DATABASE is available to BITNET,  EARN,  and NetNorth users via interactive
  messages, mail, and files in CMS PRINT or PUNCH format,  and responds based
  upon  a node's  preferred  file format.    DATABASE  will  also respond  to
  Internet requests from other networks using  mail which conforms to ARPANET
  standard RFC822.

  Issue the following interactive message from an IBM/VM environment,  to get
  the initial DATABASE HELP file.

  TELL DATABASE AT BITNIC HELP

  From a VAX/jnet environment, issue the command

  SEND DATABASE@BITNIC HELP

  Create mail,   or an  appropriate file  or send  an interactive  message to
  DATABASE@BITNIC with the commands HELP, HELP ARPANET, and HELP DESIGN for a
  complete set of help files.

  Below are examples using the DATABASE  server.   While commands can be sent
  by any of the methods previously mentioned, these examples are based on the
  IBM/VM TELL command.

  TELL DATABASE AT BITNIC LIST

  This command returns a list of retreivable subfiles as follows.

            DRINKS   Demonstration subfile
            MOVIES   Demonstration subfile
              .           .
            BITINFO  Database System subfile
            AI-LIST  ARPANET discussion forum (digest)
1

                                                                      Page 14


  TELL DATABASE AT BITNIC FIND TEXT BITNET (IN INFO-NETS TABLE

  This command tells DATABASE  to use the FIND command to  search the TEXT of
  all the  entries in  the subfile INFO-NETS  for all  instances of  the word
  BITNET and reports the  results as a table rather than  full text since the
  file would most likely be too large.  (Any result larger than 1000 lines of
  text will be returned  in a TABLE format or will respond  as if the HOWMANY
  option had been specified.)  A table returned may look like:

  GRANDS SUBJECT
  -----------------------------------------------
  498       Subject: PHYSnet
  499       Subject: Sitelists and General Info
   .           .
   .           .
  583       Subject: gateway to NJIT

  TELL DATABASE AT BITNIC FIND GS 583 (IN INFO-NETS

  DATABASE will return the contents of the entry whose subject is "gateway to
  NJIT".   GS  583 specifies the GRANDS  SUBJECT number 583 from  the ARPANET
  digest INFO-NETS.

  Unlike the ARPANET  digest subfiles some subfiles are not  searchable by by
  the index TEXT.   For example, BITINFO is the BITNET database subfile.   It
  is  a compiled  version of  the bulk  of information  contained in  BITONLY
  NAMES,  EARN NAMES,   and NETNORTH NAMES  and  identifies and characterizes
  nodes and contacts on the network.  An example of some search commands are:

  FIND SITEDESC CUNY (IN BITINFO
  FIND NODE CUNYVM (IN BITINFO FORMAT LONG
  FIND STATE NY (IN BITINFO FORMAT SHORT

  The indices being searched on are SITEDESC, NODE,  and STATE.   To find out
  what indices are valid to seach on within any subfile, issue the command:

  TELL DATABASE AT BITNIC SHOW INDEX (IN subfile

  The values chosen here to search on are CUNY,  CUNYVM,  and NY.   To get an
  idea  of what  values can  be searched  upon  within an  index,  issue  the
  command:

  TELL DATABASE AT BITNIC BROWSE indexname (IN subfile

  The format  in which  the results are  returned in  the examples  above are
  standard SPIRES format (if no other  is specified),  SHORT,  and LONG.   To
  find out what formats are valid for a particular subfile issue the command:

  TELL DATABASE AT BITNIC SHOW FORMATS (IN subfile

  where BITINFO can be substituted for the word "subfile".
1

                                                                      Page 15


  Users who  wish to  use DATABASE via  RFC822 mail,   must first  signon and
  receive a user number  (UN)  and supply a password.   To  signon,  send the
  following command to DATABASE:

  SIGNIN mypassword

  where mypassword  can be any string  of contiguous characters that  is more
  than or equal to 8 and less than or  equal to 20.   You will receive a mail
  file in return like this:

      Your signup has been processed and you have been assigned a
      user number (UN) of 00012.

  You are from that point onward,  registered  in DATABASE and can use any of
  the commands  listed above.    If you no  longer wish  to be  registered by
  DATABASE, execute the command:

  SIGNOUT 00012 mypassword

  You will no  longer be known to DATABASE  and will have to  SIGNIN again if
  you wish to use DATABASE by sending RFC822 mail.


   *************************************************************************
  * New Mailing Lists                                                       *
  ***************************************************************************

  ICECNET#@ANDREW.CMU.EDU

  ICEC,   the InterUniversity  Consortium for  Educational  Computing,  is  a
  consortium of  universities  and  colleges committed  to  developing  high-
  quality  educational  applications  for  advanced  computing  environments.
  ICECNET  has  been  the  newsletter of  ICEC  for  several  years.    Paper
  publication continues, but a copy of each issue of the newsletter will also
  be released about once a month via this mailing list.

  ICEC has  supported software  development at  member schools  and conducted
  activities for faculty  from member schools (e.g.   developers' conference,
  training  programs in  courseware development  for advanced  workstations).
  Other mechanisms  are evolving to  promote development of  good educational
  programs  for advanced,   graphics-intensive  workstations  and to  aid  in
  sharing these developments among interested parties.

  ICEC is therefore initiating an internet  mailing list (1)  for publication
  of information about ICEC,  (2)  communication among member schools related
  to internal business,  and (3)  as a forum for discussing issues related to
  the general objectives  of ICEC.   Examples of the third  category might be
  "what constitutes  high-quality courseware?",  "what Unix  workstations are
  best suited  to general educational use?",   "what mechanisms are  best for
  sharing educational developments using advanced technologies?", etc., etc.,
1

                                                                      Page 16


  etc.    Individuals,   both   from  member  schools  and   from  non-member
  organizations, are invited to contribute in this third area.

  All submissions for the monthly (paper) newsletter should be sent to:

            Patricia Clark,ICECNET editor 
                                  or
      Robert Cavalier, assistant director of ICEC 

  All requests to be added to or deleted from this list, problems, questions,
  etc., should be sent to ICECNET-REQUEST#@ANDREW.CMU.EDU.

  List maintainers: Robert Cavalier 
                    Kenneth Friend  


   *************************************************************************
  * Feedback                                                                *
  ***************************************************************************

  Date:         Wed, 1 Apr 87 19:19 EST
  From:         Thomas Kunselman 
  Subject:      The troubles at Ohstvma with the queue jams
  To:           Chris Condon 

  I don't read any  of those groups where you summarized  the problems of the
  queue jams,  but there  might be a way one might take  care of this without
  changing anything but some of the routing tables.

  I don't know how the standard for this  is or anything,  but it seems to me
  from looking at  the BITNET Topology file  that there are two  ways to send
  files to the  nodes off of OHSTVMA.   Almost  all of the nodes  that can be
  reached off of OHSTVMA can also be reached by going through WISCVM and then
  through Nebraska.   I don't remember what the node name for that university
  is right now,  as I don't have  an updated routing table.   Anyway,  if one
  sends a file from  WISCVM to say UKCC or any of a  couple of hundred nodes,
  it goes through the OSHTVMA node.   Why can't these be sent the alternative
  and less used route through Nebraska and  then to us?   Even tho this route
  is much longer to reach CCOL it would still be faster, I believe.

  When I tried reaching Nebraska two weeks  ago the links were down on either
  side so I don't know if it has been hooked up yet.   I have since misplaced
  my notes.   If  you could tell me who  to get in touch with  about this,  I
  would be happy to  do so.   Although it may take me  forever to get another
  BITNET Toplogy map with the way OHSTVMA is:-)
                                                        *
   *      *           ***          ********          *     *           ****
  * *   ** **** ** * *    *      *        *******   *   *   *   ****  *    *
 *   ***       *  * *      ******               *****       *****  ***      *
1

                                                                      Page 17


   *************************************************************************
  * NetMonth Policies                                                       *
  ***************************************************************************

  * Subscribing to NetMonth and BITNET SERVERS:

  VM users can be added to the mailing list by issuing the following command:

      TELL LISTSERV AT MARIST SUBSCRIBE NETMONTH Your_full_name

  VAX/VMS users can subscribe in a similar way:

      SEND LISTSERV@MARIST SUBSCRIBE NETMONTH Your_full_name

  If you cannot send messages in this way, you can send the following command
  as the first line of a mail file to LISTSERV@MARIST:

      SUBSCRIBE NETMONTH Your_full_name

  Arpanet users may use this method, but must address the mail to:

      LISTSERV%MARIST.BITNET@WISCVM.WISC.EDU

  A subscriber  can delete  him/herself  from  the mailing  list  by  sending
  LISTSERV@MARIST the UNSUBSCRIBE NETMONTH command.

  * Letters to the Editor:  If you have questions  or  comments  about BITNET
  or  NetMonth  that  you  would  like  printed  here,  mail  your l etter to
  BITLIB@YALEVMX.  Make sure that you  specify  in  the "Subject:"  header or
  somewhere in the letter that it is for the  NetMonth  letters  column. This
  doesn't mean that your letter will be printed, but it helps.

  * Article Submissions: The only requirements for NetMonth articles are that
  they be informative,  interesting, and  deal with  BITNET  services (or any
  other  good BITNET  related topics).  The  editor  will  inform  you of any
  changes to your writing and will submit them  for your  approval, deadlines
  permitting.  Send your articles to BITLIB@YALEVMX.

  * Printing this file:  VM users can print this file by  first copying it to
  NETMONTH LISTING and  then printing  the new file.  This will  allow  page-
  breaks and other formatting to be understood by your printer.

  ---------------------------------------------------------------------------

  A publication of the Bitnet Services Library          "Because We're Here."